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ABSTRACT 


THE  DATA  SYSTEM 


KEITH  ALLEN  KIMBALL 


DR.  HOWARD  LEE  MORGAN 


This  thesis  presents  the  DATA  (Dynamic  Alerting 
Transaction  Analysis)  System  as  an  alternative  to  a 
conventional  database  management  system.  The  DATA  System 
contains  no  records  corresponding  to  entities  but  rather  is 
simply  a time  ordered  list  of  transactions.  The  advantages 
of  DATA  In  the  areas  of  security,  integrity,  and  operational 

CP 

ease  will — discussed^  concept  of  alerting  4il4  be 

presented.  An  alerting  system  provides  facilities  to  monitor 
changes  to  the  database  In  order  to  perform  sore  action 
whenever  certain  conditions  become  true.  An  alerter  can  be 
thought  of  as  a program  that  continuously  monitors  the 
database  and  takes  some  specified  action  when  the 
corresponding  condition  becomes  true.  The  DATA  System  is  an 
excellent  tool  to  Implement  alerting  due  to  Its  ability  to 
view  the  database  at  previous  points  In  time.  This  work 
describes  the  implementation  of  the  DATA  System. 
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CHAPTER  I 

This  thesis  presents  the  Dynamic  Alerting  Transaction 
Analysis  (DATA)  System  as  an  alternative  to  conventional 
databases.  Advantages  of  this  system  will  be  explored  and 
the  concept  of  alerting  will  be  presented.  The  DATA  System 
will  be  shown  to  he  an  excellent  tool  to  implement  alerting. 
The  Implementation  of  this  system  will  be  discussed. 
Applications  for  the  system  will  be  suggested. 

Conventional  databases  are  a collection  of  records  used 
to  model  certain  entities.  One  physical  record  corresponds 
to  a given  entity  and  describes  the  current  state  of  that 
entity.  For  example,  in  a personnel  system  there  could  exist 
a record  corresponding  to  the  entity  John  Smith.  This 
record  would  contain  information  such  as  his  name,  employee 
number,  current  address,  and  current  salary.  In  the  DATA 
System  there  exists  no  physical  records  corresponding  to 
entities.  The  database  contains  no  data  records  as  such  but 
rather  is  simply  a time  ordered  list  of  transactions.  For 
example,  the  entity  John  Smith  would  be  represented  by 
several  transactions.  The  first  transaction  would 
correspond  to  the  hiring  of  John  Smith.  This  transaction 
would  contain  his  name,  employee  number,  initial  salary,  and 
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Initial  address.  As  time  passed  more  transactions  would 
affect  John  Smith.  There  would  he  transactions 
corresponding  to  him  getting  a raise  and  other  transactions 
corresponding  to  him  changing  addresses.  The  current  state 
of  the  entity  can  be  extracted  from  this  collection  of 
transactions.  This  current  state  corresponds  to  the 
conventional  database  record.  The  DATA  database  contains 
more  Information  than  the  conventional  database.  Whereas  the 
conventional  database  provides  a static  picture  of  the 
entity,  the  DATA  database  provides  a dynamic  picture  of  the 
entity  since  It  contains  all  changes  the  entity  has 
unde  rgone  . 

DATA  databases  may  be  viewed  from  two  levels.  On  the 
higher  level  they  appear  as  ordinary  databases.  Retrieval, 
deletion,  addition,  and  modification  of  records  may  be 
performed.  An  additional  feature  of  a DATA  database  on  the 
higher  level  Is  that  It  can  be  viewed  as  It  existed  at  any 
previous  point  In  time. 

On  the  lower  level,  the  database  may  be  viewed  as  a 
time  ordered  list  of  transactions.  The  three  basic  typea  of 
transactions  are  deletion,  modification,  and  addition.  Once 
a transaction  Is  entered  In  the  list.  It  Is  never  modified 
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or  deleted.  The  format  and  content  of  tranaactlons  should 
be  well  documented  so  programs  can  extract  from  this  list 
and  perform  some  action  based  on  the  content  of  the 
transaction.  The  minimal  amount  of  Information  a transaction 
should  contain  Is  the  type  of  transaction,  time  of  the 
transaction,  a pointer  to  the  previous  transaction  on  the 
entity,  and  the  new  value  of  any  data  changed  by  the 
transaction.  The  dynamic  database  Is  constantly  growing. 

An  alerting  system  provides  facilities  to  monitor 
changes  to  the  database  In  order  to  perform  some  action 
whenever  certain  conditions  become  true.  Alerters  are  the 
basis  of  the  alerting  system.  An  alerter  associates  a name 
(of  the  alerter),  a condition  to  be  evaluated  , and  an 
action  to  be  taken  when  the  condition  Is  met.  An  alerter 
can  be  thought  of  as  a program  that  continuously  monitors 
the  database  and  takes  some  specified  action  when  the 
specified  condition  becomes  true. 

For  example.  In  a database  containing  information  about 
airline  reservations,  an  alerter  called  FLIGHTFULL  could  be 
used  to  monitor  the  number  of  available  seats  on  a flight  In 
order  to  print  a message  when  no  seats  are  available.  In 
this  example  the  alerter  name  Is  FLIGHTFULL,  the  alerting 
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condition  Is  the  number  of  available  seats  becoming  zero, 
and  the  associated  action  Is  the  message  stating  the  flight 
number  and  the  fact  no  seats  are  available. 

The  concept  of  the  DATA  System  has  appeared  In  other 
systems.  Many  of  the  Ideas  for  this  thesis  came  from  the 
similarity  found  between  DATA  and  differential  databases 
[3].  A differential  file  Is  a small  data  file  containing 
changes  to  a large  readonly  master  file.  One  way  of  looking 
at  a DATA  database  Is  as  a differential  database  with  the 
blocks  already  dumped  as  the  large  readonly  master  files  and 
all  blocks  written  after  the  dump  as  the  differential  files. 

A common  practice  In  the  maintenance  of  databases  Is  to 
keep  a log  tape.  This  log  tape  contains  a history  of  changes 
to  the  database.  A DATA  database  can  be  viewed  as  this 
principle  taken  to  the  extreme  where  the  log  tape  becomes 
the  data  of  the  database. 

This  type  of  database  stores  data  In  a form  quite 
different  than  the  normal  user  expects  to  see  It.  The 
normal  user  expects  to  see  tuples  while  the  database  stores 
transactions  used  to  form  the  tuples.  System  P's  (9]  view 
uses  the  concept  of  users'  view  of  the  data  being  quite 
different  from  the  physical  storage  of  the  data. 


Page  8 


Alerters  change  the  concept  of  a databaae  managenent 
system  from  a passive  to  an  active  system*  Previously  the 
user/da tabase  interface  consisted  of  a subroutine  call.  The 
user  would  query  the  database  system  and  then  wait  for  a 
response.  The  user  program  and  database  system  did  not 
operate  in  parallel  and  the  database  responded  only  when 
spoken  to.  Under  an  active  database  system,  user  programs 
and  database  systems  operate  in  parallel  and  both  are 
capable  of  action. 

Six  general  advantages  can  be  realized  by  DATA 
databases.  These  advantages  are  derived  from  a similarity 
to  differential  files  [3].  One  advantage  is  related  to 
security  and  shows  that  no  information  is  lost  due  to 
update.  Three  are  related  to  database  integrity  and  show 
that  DATA  databases  can  reduce  backup  cost  and  provide 
relatively  fast  and  easy  recovery  from  loses.  The  final  two 
advantages  are  operational  and  show  that  DATA  databases  can 
simplify  software  development  and  provide  past  views  of  the 
database . 

No  information  is  ever  lost  due  to  update  when  using  a 
DATA  database.  The  physical  database  is  simply  a list  of 
transactions.  Once  a transaction  is  entered  on  the  list,  it 
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la  never  modified.  Becauae  the  databaae  can  be  viewed  es  a 
series  of  transactions.  It  Is  difficult  to  hide  nefarious 
activity.  All  changes  to  the  database  are  localized  to  a 
small  area.  By  viewing  the  databaae  as  a series  of 
transactions,  this  small  area  can  be  scanned  for 
Iraproprlet les . 

DATA  databases  provide  the  ability  to  place  consistency 
contralnts  on  the  database  that  could  not  be  placed  on  a 
conventional  database.  An  example  of  such  a constraint  Is 
"accept  no  more  than  ten  changes  from  a user  within  one 
hour".  This  constraint  can  be  enforced  by  viewing  the 
database  as  a series  of  transactions. 

A DATA  database  can  be  easily  dumped.  The  list  of 
transactions  are  simply  appended.  The  only  part  of  the 
files  which  need  to  be  dumped  are  those  added  since  the  last 
dump.  This  substantially  reduces  the  time  required  to  dump 
the  database.  Since  transactions  are  simply  appended,  there 
Is  no  danger  in  dumping  the  database  while  It  Is  online* 

Fast  recovery  from  hard  loses  Is  provided  by  DATA 

i 

databases.  If  a block  on  the  disk  Is  destroyed.  It  can  be 


simply  reloaded  from  a backup  dump  and  processing  can 
continue.  This  is  possible  because  transactions  are  never 
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modified  once  they  are  entered  on  the  list  of  trans act  Iona • 
The  database  could  be  allowed  to  run  while  blocks  were  being 
copied.  If  the  bad  block  was  referenced  either  an  exception 
could  be  returned  or  the  program  would  wait  for  the  block  to 
be  copied. 

Recovery  from  soft  loss  is  also  provided.  Occasionally 
programs  Incorrectly  update  the  database.  To  recover  from 
this  situation  the  database  Is  backed  up  to  a point  In  time 
before  the  erroneous  program  ran.  The  conventional  database 
management  system  maintains  a log  tape  of  "before  images"  of 
changes  to  the  database.  Backing  up  the  database  to  a 
previous  point  In  time  is  accomplished  by  reading  the  log 
tape  backwards  and  applying  the  "before  Images"  until  the 
desired  point  in  time  Is  reached.  When  the  database  Is  being 
updated,  both  database  and  log  tape  records  must  be  written. 
When  the  database  is  being  backed  up  the  log  tape  Is  read 
backwards  and  changes  written  throughout  the  database.  DATA 
provides  recovery  from  soft  loss  without  maintaining  a log 
tape.  Backing  up  the  database  to  a previous  point  In  time 
is  accomplished  by  simply  discarding  all  transactions  after 
the  error  occurred. 


The  development  of  application  programs  can  be 
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slnpllfled  by  a DATA  database.  At  some  desired  point  In  tlm*' 
the  list  of  transactions  could  be  branched  Into  two  separat- 
llsts.  One  list  would  constitute  a production  system  and  the 
other  list  would  constitute  a developmental  system  running 
In  parallel.  Both  systems  would  share  the  same  base  list  of 
transactions.  Any  program  being  tested  would  update  the 
database  via  the  developmental  list  of  transactions.  These 
changes  will  not  affect  the  production  database.  Thus 
programs  can  be  tested  against  the  large  central  database 
without  affecting  the  production  database. 

The  database  may  be  viewed  as  It  existed  at  any 
previous  point  in  time.  By  Ignoring  all  transactions  since  a 
certain  time  the  database  Is  viewed  as  It  existed  at  that 
point  In  time.  This  property  can  be  used  In  an  efficient 
Implementation  of  complex  forms  of  alerting.  Another  use  of 
this  feature  Is  to  freeze  a program's  view  of  an  online 
database  at  some  point  In  time.  The  program  would  view  the 
database  as  It  existed  at  that  point  In  time  while  online 
processing  continued. 
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CHAPTER  II 

An  alerter  associates  a nane  (of  the  alerter) » a 
condition  to  be  evaluated,  and  an  action  to  be  taken  when 
the  condition  becomes  true*  The  complexity  of  the  condition 
determines  the  utility  of  the  alerting.  The  simplest  (and 
most  primitive)  way  to  Implement  an  alerting  system  would  be 
to  evaluate  all  conditions  associated  with  alerters  after 
every  change  to  the  database  and  to  take  the  specified 
action  If  the  condition  Is  true.  This  Is  very  Inefficient 
especially  when  one  realizes  that  the  condition  could  be  any 
predicate.  This  predicate  could  be  time  consuming  to 
evaluate.  Previous  authors  [1,  2,  5,  6]  have  distinguished 
three  levels  of  alerting  conditions.  These  three  levels  are 
simple,  structural,  and  complex  alerting  conditions. 

I 

( 

Simple  alerting  conditions  are  the  easiest  to 
Implement.  Simple  alerting  conditions  deal  only  with  one 
relation  and  the  condition  can  be  evaluated  by  referencing 
only  the  old  and  new  copies  of  the  tuple  being  chsnged.  An 
I example  of  a simple  alerting  condition  Is  "tell  me  when  ^ 

! anyone  receives  a raise  over  2SZ''.  ^ 

Structural  alerting  conditions  deal  with  changes  in  the 

I 

I 

i 
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strucCure  of  Che  database.  These  require  che  aoniCorlng  of 
more  Chan  one  relation.  Consider  Che  following  database: 

PEOPLE  PFLATION  ( 

NAME  KEY  ALPHA  15; 

AGE  NUMBER; 

CAR  ALPHA  10)  ; 

CARS  RELATION  ( 

CAR  KEY  ALPHA  10; 

PRICE  NUMBER  ) ; 

An  example  of  a structural  alerter  is  "tell  me  when  a person 
under  30  years  of  age  owns  a car  priced  over  $10,000”.  This 
requires  that  both  che  CARS  and  PEOPLE  relations  be 
moni Cored  . 

Complex  alerting  deals  with  a more  global  view  of  Che 
database.  Previous  authors  [5]  have  broken  these  down  into 
two  classes.  The  first  class  of  complex  alerting  conditions 
require  the  use  of  time.  An  example  of  a time  spanning 
alerting  condition  is  "tell  me  when  a car  has  three  price 
Increases  in  one  year”.  The  second  class  of  complex  alerting 
conditions  are  statistical  alerts.  An  example  of  a 
statistical  alerter  is  "tell  me  when  the  average  price  of  a 
car  is  over  $50no". 
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In  a real  world  situation  it  seems  desirable  to  limit 
the  scope  of  the  alerting  condition*  It  is  felt  that  the 
database  system  should  only  support  simple  alerting 
conditions.  This  does  not  preclude  the  user  from  writing 
programs  which  would  emulate  the  other  forms  of  alerting 
conditions.  A DATA  database  will  contain  all  the 
Information  necessary  for  implementing  the  other  two  classes 
of  alerting  conditions  via  user  programs. 

The  first  reason  the  alerting  condition  was  limited  to 
simple  alerting  Is  due  to  timing  considerations.  Previous 
papers  have  not  fully  specified  when  the  triggering  of  an 
alerter  occurs.  It  has  been  stated  that  the  alerter  is 
triggered  after  the  update  and  thus  can  not  interfere  with 
the  update  (2).  Alerters  will  now  be  triggered  before  the 
next  update.  In  a conventional  database  management  system 
this  is  a necessity  because  the  evaluation  of  the  alerting 
condition  could  be  changed  by  the  second  update.  If  alerting 
conditions  were  time  consuming  to  evaluate  then  the  next 
update  would  have  to  wait  for  this  evaluation  and  the 
database  would  be  very  slow.  Restricting  alerting 
conditions  to  simple  alerting  guarantees  a relatively  cheap 
evaluation  of  the  condition. 
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An  efficient  Implementation  of  the  more  complex  forms 
of  alerting  would  require  auxiliary  structures  to  be 
created.  For  example,  consider  the  alerter  "tell  me  when 
the  average  salary  of  department  46500  Is  over  $25,000".  An 
efficient  way  to  Implement  this  Is  to  create  a structure 
containing  the  number  of  people  in  department  46500  and  the 
sum  of  their  salaries.  V’hen  a change  occurs  in  the  salary 
domain  of  a tuple  whose  department  number  Is  46500  then  this 
structure  Is  updated.  If  the  sum  of  salaries  divided  by  the 
number  of  people  Is  over  25000  then  the  action  Is  taken.  The 
point  Is  that  auxiliary  structures  are  created  and  they  may 
be  very  large.  For  example.  If  Instead  of  department  number 
being  46500  the  request  was  for  any  department  then  a 
auxiliary  structure  consisting  of  a tuple  per  department 
would  be  created.  The  size  of  this  auxiliary  structure  would 
be  very  large.  The  declarer  of  the  alerter  might  not  be 
cognizant  of  this  large  structure.  This  is  not  a desirable 
feature  of  an  actual  database  management  aystem. 

Just  as  It  was  desirable  to  limit  the  condition  of  an 
alerter.  It  seems  desirable  to  limit  the  action  an  alerter 
can  perform.  Previous  authors  [2,5,6]  have  stated  that 
the  triggering  of  an  alerter  should  generate  a message.  In 
a conventional  database  management  system  It  Is  necessary 
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for  the  message  to  contain  the  value  of  any  domains  that  the 
declarer  of  the  alerter  might  be  Interested  in.  This  la 
because  once  the  alerter  is  triggered  the  database  is  being 
updated  and  these  values  might  change.  In  the  DATA  System 
the  message  need  only  to  consist  of  the  alerter  name  and  a 
pointer  to  the  transaction  triggering  the  alerter.  The  value 
of  any  domains  of  Interest  can  be  extracted  from  the 
transact  ion . 

Structural  and  complex  alerting  conditions  could  be 
Implemented  by  requiring  users  to  write  programs  that  use 
simple  alerters  to  note  changes  in  the  database.  The 
programs  would  then  evaluate  the  more  complicated  condition 
to  decide  If  tlie  action  should  be  taken.  These  appear  as 
ordinary  alerters  except  they  may  not  occur  before  the  next 
update.  This  Is  because  after  the  simple  alerter  is 
triggered,  the  updating  of  the  database  continues.  The 
burden  of  the  decision  of  how  to  optimize  complicated 
alerting  is  shifted  from  the  system  to  the  user.  The  user 
makes  the  s to  rage /pr oces sor  time  tradeoffs,  and  the  user  is 
aware  of  the  auxiliary  structures  his  programs  use. 

This  approach  to  structural  and  complex  alerting 
conditions  depends  upon  a list  of  transactions.  After  the 
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simple  alerter  Is  triggered,  processing  continues  and  the 
database  Is  undergoing  change.  While  the  structural  alerting 
condition  Is  being  evaluated,  the  database  needs  to  be 
viewed  at  the  time  the  simple  alerter  was  triggered,  DATA 
provides  the  ability  to  view  the  database  at  that  point  In 
t Ime  , 

Complex  alerting  conditions  require  the  ability  to  view 
the  database  at  previous  points  In  time.  This  Is  provided  by 
the  DATA  System,  Complex  alerters  are  also  Interested  In  the 
changes  the  entitles  have  undergone.  This  feature  Is 
provided  by  viewing  the  database  as  a time  stamped  list  of 
transact  Ions , 

The  alerting  system  proposed  restricts  alerting 
conditions  to  simple  alerting  conditions  and  restricts 
alerting  actions  to  sending  a message  consisting  of  the 
alerter  name  and  a transaction  number.  The  alerting  action 
will  occur  after  the  update  which  triggered  it  and  before 
any  other  updates.  Users  are  able  to  Implement  structural 
and  complex  alerting  conditions  by  writing  programs  that  use 
simple  alerting  to  note  changes  In  the  database  and  then 
evaluate  the  more  complicated  conditions.  The  programs 
require  the  ability  to  view  the  database  at  previous  points 
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In  time  and  to  view  the  database 
transactions.  The  DATA  System  Is 
Implement  alerting. 


as  a time  stamped 
an  excellent  tool 


list  of 
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CHAPTER  III 

This  chapter  describes  the  Implementation  of  the  DATA 
System.  The  database  system  Implemented  Is  a simple 

I 

relational  database  system.  A database  definition  consists 
j of  a database  name,  relation  definitions,  and  domain 

I definitions.  Access  to  the  database  Is  via  a program  which 

I 

provides  the  facilities  of  a typical  database  manipulation 

language.  The  commands  to  access  the  database  are  not 

I 

I embedded  within  a programming  language.  The  commands 

I provided  are  add,  delete,  modify,  flnd(at  key  condition 

I only),  show,  display,  alert,  settime,  and  rollback.  The 

i 

three  unusual  commands  are  alert,  settime,  and  rollback.  The  j 

t 

alert  command  creates  alerters;  the  rollback  command  backs  I 

! 

the  database  up  In  time;  and,  the  settime  command  allows  the 
database  to  be  viewed  at  a previous  point  In  time.  The 
system  Is  Implemented  using  a conventional  database 
management  system. 
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An  overall  picture  of  the  DATA  System  la: 


* — - * 

* DB/DFSCRIBE  * 

*  * 


V 


databases  relations  domains 


DATABASE 

DEFINITION 

MODULE 


V 

* 

* DB/PROGRAM  * 

*  * 

A A 

# # 

V V 


. transactions  indexsets  . '.alerters  evaluatealert  • 


TRANSACTION  ALERTER 

MODULE  MODULE 

THE  DATA  SYSTEM 

The  database  is  described  by  running  a program  called 
DB/DESCRIBE.  This  program  prompts  the  user  to  describe  the 
database.  The  first  Input  Is  the  database  name.  The  database 
name  Is  stored  In  a relation  as  follows: 


DATABASES  RELATION  ( 

DBNAME  KEY  ALPHA  15; 
DBNUMBER  NUMBER) ; 


The  DBNAME  Is  the  database  name.  DBNUMBER  Is  a number 
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associated  with  the  database  name  and  is  used  to  identify 
the  da  tabase  . 

The  next  Inputs  are  the  relation  names.  Relation  names 
are  stored  In  a relation  as  follows: 

RELATIONS  RELATION  ( 

RELOBNUMBER  KEY  NUMBER; 

RELNAME  KEY  ALPHA  15; 

RELNUMBER  NUMBER; 

RFLKEYSIZE  NUMBER; 

RELSIZE  NUMBER) ; 

The  R ELURNITMRRP  is  the  number  of  the  database  which  owns  the 
relation.  The  RFI.NAME  is  the  name  of  the  relation.  Relations 
within  a database  must  have  unique  names.  RELNUMBER  is  a 
number  assigned  to  distinguish  between  relations  of  the  same 
database.  R FI.  OBNUMBER  and  RELNUMBER  uniquely  identify  the 
relation.  RELKK^SIZE  and  RFLSIZE  are  the  number  of 
characters  in  a key  and  in  a tuple  of  the  relation. 

The  final  Inputs  are  the  domain  definitions.  Domains 
are  described  In  a relation  as  follows: 

DOMAINS  RELATION  ( 

DOMDBNUMBER  KEY  HUMBER; 


* 
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nOMRELNUMBER  KEY  NUMBER; 
nOMNAME  KEY  ALPHA  15; 

OOMAALPHA  NUMBER; 

DOMAKEY  NUMBER; 
nOMl.OC  NUMBER; 
nOMKEYLOC  NUMBER; 
nOMSIZE  NUMBER); 

DOMPBNUMBER  and  DOMRELNUMBER  Identify  the  database  and 
relation  which  own  the  domain.  The  DOMNAME  is  the  name  of 
the  domain.  Domains  must  have  unique  names  within  a 
relation.  DOMAAI.PHA  and  DOMAKEY  are  booleans  indicating  if 
the  domain  Is  an  alpha  or  if  the  domain  is  a key.  The  DOMLOC 
and  DOMKEYLOf  contain  the  offset  of  the  domain  within  a 
tuple  and  within  a key.  If  the  domain  is  not  a key  its 
DOMKEYLOC  is  zero.  DOMSIZE  is  the  size  of  the  domain  in 
terms  of  characters. 

Consider  the  following  database  definition: 

PERSONNEL  DATABASE  ( 

PEOPLE  RELATION  ( 

FTRSTNAME  KEY  ALPHA  5; 

LASTNAME  KEY  ALPHA  10; 

ROOM  ALPHA  A;  ) ; 
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ROOMS  RELATION  ( 

ROOM  KEY  ALPHA  4 ; 

EXTENSION  NUMBER  ; ) ; ) ; 

The  database  deflrvition  would  be  stored  as  follows: 

DATABASES  (prefix  column  names  by  DB) 

NAME  NUMBER 

PERSONNEL  1 

RELATIONS  (prefix  column  names  by  REL) 

DB#  NAME  NUMBER  KEYSIZE  SIZE 

1 PEOPLE  1 15  19 

1 ROOMS  2 4 16 

DOMAINS  (prefix  column  names  by  DOM) 


DB# 

REL# 

NAME 

ALPHA 

KEY 

LOG 

KEYLOC 

SIZE 

1 

1 

FI  RSTNAME 

YES 

YES 

0 

0 

5 

1 

1 

LASTNAME 

YES 

YES 

5 

5 

10 

1 

1 

ROOM 

YES 

NO 

15 

0 

4 

1 

2 

ROOM 

YES 

YES 

0 

0 

4 

1 

2 

EXTENSION 

NO 

NO 

4 

0 

12 

Appendix  B contains  syntax  diagrams  and  semantic 


definitions  for  a database  definition  language*  This  is 
intended  as  a logical  equivalent  to  what  the  user  is 
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prompted  to  Input. 

The  database  is  accessed  by  running  a program  called 
DB/PROGRAM.  This  program  manipulates  two  basic  structures. 
The  first  structure  is  called  TRANSACTIONS  and  consists  of  a 
time  ordered  list  of  transactions.  The  format  of  this 
struct  ur e is  : 

TRANSACTIONS  RELATION  ( 

TRANSDBNUMBER  KEY  NUMBER; 

TRANSNUMBER  KEY  NUMBER; 

TRANSTYPE  NUMBER; 

TRANSRELNUMBER  NUMBER; 

TRANSPREVNO  NUMBER; 

TRANSYEAR  NUMBER; 

TRANSUAY  NUMBER; 

TRANSHOUR  NUMBER; 

TRAMSMINURE  NUMBER; 

TRANSSECONU  NUMBER; 

TRANSDATA  ALPHA  512); 

The  TRANSDBNUMBFR  identifies  the  database  affected  by  the 
transaction.  The  TRANSNUMBRR  is  a number  assigned  to 
distlnquish  between  transactions  on  a given  database.  The 
TRANSDBNUMBFR  and  the  TRANSNUMBER  identify  a transaction. 
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The  TRANSTYPE  specifies  the  type  of  transaction*  The  types 
of  transactions  are  addition,  deletion,  and  modification. 

The  TRANSPELNHMBER  Is  the  relation  number  of  the  tuple  being 
affected  by  this  transaction.  TRANSPREVNO  is  the  TRANSNUMBER 
of  the  previous  transaction  on  the  entity.  All  transactions 
upon  an  entity  are  linked  via  this  domain.  TFANSYEAR, 
TRANSDAY,  TRANSHOUR,  TRANSMINUTE  and  TRANSSECOND  datetime 


stamp  the  transaction.  TRANSDATA  Is  the  new  tuple.  In 
practice  only  the  number  of  characters  necessary  to  contain 
the  new  tuple  are  stored  In  the  database. 


The  other  basic  structure  manipulated  by  DB/PROGRAM  is 
called  INDEXSETS.  The  tuples  of  INDEXSETS  are  used  to  locate 
the  most  recent  transactions  upon  the  entitles.  This 
structure  provides  the  head  of  the  linked  list  of 
transactions  upon  an  entity.  The  structure  Is  as  follows: 


INDEXSETS  RELATION  ( 

ISDBNUMBER  KEY  NUMBER; 
ISREI.NUMBER  KEY  NUMBER; 
ISKEY  KEY  ALPHA  256; 
ISDELETE  NUMBER; 
TSTRANSNUMBER  NUMBER); 


I 


I 


I 
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The  ISDBNUMBER  and  ISRELNUMBEP  Identify  the  database  and 


r 


Page  26 

relation  to  which  the  key  belongs.  ISREY  Is  the  key  uniquely 
identlflng  a tuple.  ISDELETE  Is  a boolean  Indicating  whether 
or  not  there  is  a current  tuple  In  the  database  with  that 
key  value.  ISDELETE  Is  true  If  a tuple  existed  with  the  key 
value  and  then  was  deleted  from  the  database.  I STRANSNUMEER 
is  the  TPANSMDMBFR  of  the  last  transaction  upon  the  entity. 
This  provides  the  head  of  the  linked  list  of  transactions 
upon  the  entity. 

Consider  the  following  series  of  commands: 

ADD  PEOPLE  (FIRSTNAME  - "JAMES",  LASTNAME- "CARTER" ) 

MODIFY  PEOPLE  ( ROOM  - "BLUE"  ) 

ADD  ROOMS  ( ROOM  » "BLUE",  EXTENSION  - 1) 

ADD  PEOPLE  (FIRSTNAME  - "BFPT",  LASTNAME-"LANCE") 

MODIFY  PEOPLE  ( ROOM  - "RED"  ) 

ADD  ROOMS  ( ROOM  - "RED",  EXTENSION  - 2) 

ADD  PEOPLE  (FIRSTNAME  - "CYRUS",  LASTNAME-"VANCE" ) ' ' 

MODIFY  PEOPLE  ( ROOM  - "PINK"  ) 

ADD  ROOMS  ( ROOM  - "PINK",  EXTENSION  - 3) 

DELETE  PEOPLE  (FIRSTNAME  - "BERT",  LASTNAME-"LANCE") 

The  database  would  be  stored  as  follows: 


TRANSACTIONS  (prefix  column  names  by  TRANS) 


T 


Page  27 


DB# 

# 

TYPE 

REL# 

PREV# 

DATA 

1 

10 

n 

1 

5 

1 

9 

A 

2 

0 

PINK3 

1 

8 

M 

1 

7 

CYRUSVANCE  PINK 

1 

7 

A 

1 

0 

CYRUSVANCE 

1 

8 

A 

2 

0 

RED  2 

1 

5 

M 

1 

4 

BERT  LANCE  RED 

1 

4 

A 

1 

0 

BERT  LANCE 

1 

3 

A 

2 

0 

BLUEl 

1 

2 

M 

1 

1 

JAMESCARTER  BLUE 

1 

1 

A 

1 

0 

JAMF.SCARTEP 

INnKXS  RTS 

( p ref 

lx  column  names  by  IS) 

DB# 

REl, /» 

DELETE 

TRANS 

KEY 

1 

1 

NO 

2 

JAMESCARTER 

1 

1 

YES 

10 

BERT  LANCE 

1 

1 

NO 

a 

CYRUSVANCE 

1 

2 

NO 

3 

BLUE 

1 

2 

NO 

6 

RED 

1 

2 

NO 

9 

PINK 

The 

database  system 

Implemented  contains  ten  commands* 

A simplified  description  of  the  Implementation  follows* 


The  APD  command  creates  a new  tuple  In  the  database 
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This  command  contains  a relation  name  and  Initial  value*  for 
various  domains.  The  first  step  Is  to  verify  that  no  tuple 
exists  with  the  same  key  value  as  the  tuple  being  created. 

After  this  Is  Hone  a transaction  Is  entered  on  the  list  of 
transactions.  This  transaction  will  be  of  type  addition. 

The  datetime  stamp  Is  placed  In  the  appropriate  domains.  The 
TRANSDATA  domain  contains  the  new  tuple  of  the  specified 
relation.  The  TRAMSRELNUMBRR  Is  the  number  associated  with 
the  specified  relation.  The  TRANSPREVNO  Is  zero  If  there  was 
no  previous  transaction  on  the  entity.  If  there  was  a 
previous  transaction  on  the  entity,  the  TRANSNUMBER  of  the 
previous  transaction  (which  must  have  been  a deletion)  will 
be  stored  In  the  TRANSPREVNO  domeln.  Finally  the  INDEXSETS 
relation  Is  updated.  If  there  was  no  previous  transaction  on 
Che  entity,  a new  tuple  of  INDEXSETS  Is  created.  This  tuple 
points  to  Che  new  tuple  of  TRANSACTIONS.  If  there  was  a 
previous  transaction  on  Che  entity,  the  corresponding  tuple 

i 

of  INDEXSETS  has  Its  ISDELETE  domain  reset.  This  tuple  also 
points  to  Che  new  tuple  of  TRANSACTIONS. 

The  DELETE  command  deletes  a tuple  from  the  database. 

This  command  contains  a relation  name  and  values  Co  which 

I Che  key  must  match.  First  a tuple  Is  located  matching  the  | 

specified  key  values.  Next  a transaction  Is  entered  on  the  | 


I 
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list  of  transactions  with  a type  of  deletion*  Finally  the 
tuple  in  INDEXSFTS  is  marked  with  ISDELETE  as  true  and 
pointed  to  the  recently  created  transaction* 

The  MODIFY  command  requires  a tuple  to  be  currently 
located  ( via  a previous  FIND  or  ADD  command  )*  This  command 
contains  a relation  name  and  new  values  for  nonkey  Items* 

The  tuple  Is  entered  on  the  list  of  transactions  with  the 
new  values  of  the  nonkey  Items*  The  corresponding  INDEXSETS' 
tuple  Is  pointed  to  the  new  transaction* 

The  FIND  command  requires  a relation  name  and  values  to 
which  keys  must  match*  The  program  searches  INDEXSETS  for  a 
tuple  matching  the  specified  key  values*  If  no  such  tuple 
exists,  an  exception  Is  returned*  If  a tuple  is  found  with 
Its  ISDELETE  domain  true  and  If  the  database  Is  being  viewed 
from  the  current  time,  an  exception  Is  returned*  Otherwise 
the  corresponding  tuple  of  TRANSACTIONS  Is  read*  If  the 
database  Is  being  viewed  from  the  current  time,  the  command 
Is  complete.  If  Che  database  Is  being  viewed  from  a past 
time,  transactions  upon  this  entity  are  read  until  one  la 
found  with  a datetlme  stamp  less  Chan  the  time  that  Che 
database  Is  being  viewed  from*  If  such  a transaction  exists 
and  Its  type  Is  not  deleted,  the  command  is  sucessful  else 
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an  exception  is  returned  stating  that  there  was  no  such 
tuple  at  the  specified  time. 

The  SF.TTIMF  command  allows  the  database  to  be  viewed 
from  previous  points  in  time.  S ETTIME-CURRFMT  states  that 
the  database  should  be  viewed  from  the  current  time.  SETTIME 
by  Itself  asks  the  time  that  the  database  is  being  viewed 
from.  SETTIHE>  77/155  @ 23:12:11  implies  that  the  database 
should  be  viewed  as  it  existed  at  11:12:11  p.m.  on  the  155th 
day  of  1977. 

The  SHOW  command  is  used  to  display  the  relation  and 
domain  names.  SHOV'  by  itself  displays  all  relation  names  of 
the  database.  SHOW  <relatlon  name>  displays  the  domain 
names  of  that  relation.  This  is  accomplished  by  reading  the 
RELATIONS  and  nOMAIMS  relations. 

The  niSPI.AY  command  requires  a relation  name.  It  causes 
values  in  the  current  tuple  of  relation  name  to  be  displayed 
at  the  terminal.  For  each  domain  Its  name  and  Its  value 
within  the  current  tuple  Is  displayed. 

The  ROLLPACK  command  backs  up  the  database  to  a 
specified  time.  This  Is  accomplished  by  simply  updating 
pointers  In  INDEXSETS.  No  tuples  of  TRANSACTIONS  are 
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deleted.  The  rollback  is  accomplished  by  locating  each  tuple 
in  INDEXSETS  and  then  reading  the  corresponding  TRANSACTIONS 
tuple.  If  the  TRANSACTIONS'  tuple  is  beyond  the  rollback 
point,  the  linked  list  of  transactions  on  this  entity  are 
read  until  one  la  found  before  the  rollback  point.  If  a 
transaction  Is  found  before  the  rollback  point,  the 
INDEXSETS  tuple  Is  updated  to  point  at  this  transaction  and 
the  ISDFLETE  domain  is  updated  based  on  the  type  of 
transaction.  If  no  transaction  is  found  before  the  rollback 
point,  the  INPEXSETS  tuple  is  deleted. 

The  final  command  Implemented  is  the  ALERT  command. 
Alerters  In  this  system  are  restricted  to  simple  alerting 
conditions  and  the  associated  action  is  merely  a display  at 
the  terminal.  This  command  is  used  to  create,  display, 
enable,  disable,  and  cancel  alerters.  ALERT  by  itself  causes 
the  names  of  all  alerterV  to  be  displayed.  ALERT  <alert 
name>  causes  the  text  and  state  of  <alert  name>  to  be 
displayed.  ALERT  <alert  name>  « CANCEL  causes  <alert  name> 
to  be  cancelled.  An  alerter  can  be  in  one  of  two  states.  If 
an  alerter  is  enabled,  it  is  a candidate  to  be  triggered.  If 
an  alerter  is  in  a disabled  state,  the  alerter  may  not  be 
triggered  until  it  is  enabled.  The  alerter  may  be  placed  in 
these  states  hy  the  commands  ALERT  <alert  name>  * ENABLE  or 
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by  ALERT  <alert  name>  ■ DISABLE  • An  example  of  Che 
creation  of  an  alerter  is: 


ALERT  RICRAISE  (MODIFY  OF  PEOPLE) 


SALARY. NFV  > SALARY. OLD  * 1.1 


BIGRAISE  Is  the  name  of  the  alerter.  The  MODIFY  OF  PEOPLE 
states  Chat  Che  alerter  should  be  evaluated  after  Che 
modification  of  the  relation  called  PEOPLE.  The  condition  Is 
SALARY. NEW  > S ALARY . OLD* 1 . 1 (l.e.  a lOt  raise).  SALARY  Is 
assumed  to  be  a numeric  domain  of  PEOPLE.  When  an  alerter 
Is  evaluated  two  tuples  can  be  seen.  If  the  type  of 
Cransacton  Is  nodlFlcatlon,  they  are  the  tuple  before  and 
after  the  modification.  For  transactions  of  type  addition  or 
deletion,  Che  two  tuples  are  Identical.  In  Che  case  of  a 
transaction  of  type  addition,'  both  tuples  are  the  result  of 
the  addition.  Tn  the  case  of  a transaction  of  type  deletion, 
both  tuples  are  Che  tuple  before  the  deletion.  Alerters  are 
stored  In  two  structures.  One  structure  contains  Che  alerter 
definition  and  Che  other  contains  Information  on  when  to 
evaluate  Che  alerter.  The  alerter  definition  Is  stored  In  a 
structure  as  follows: 


ALERTERS  RELATION  ( 


ALORNUMBEP  FEY  NUMBER; 
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ALNAME  KEY  ALPHA  15; 

ALNUMBER  NUMBER; 

AI.ENABLE  NUMBER; 

AI.TEKT  ALPHA  256)  ; 

ALDBNUMBER  Is  the  number  of  the  database  to  which  the 
alerter  belongs.  AI.MUMBEP  Is  a number  used  to  dlstlnqulsh 
the  alerter  from  other  alerters  in  a given  database.  ALNAME 
is  the  name  of  the  alerter.  ALNAME  must  be  unique  within  a 
given  database.  ALENABLE  is  a boolean  indicating  if  the 
alerter  is  in  an  enabled  or  disabled  state.  ALTEXT  is  the 
text  of  the  alerter. 

The  structure  used  to  determine  when  to  evaluate  the 
alerting  condition  is  as  follows: 

EVALUATEALERT  RELATION  ( 

EVOBNUMBER  KEY  NUMBER; 

FVPFLNUMBER  KEY  NUMBER; 

EVTYPE  KEY  NUMBER; 

EVALNUMBER  KEY  NUMBER) 

EVOBNUMPER  and  FVFELNUMBEP  are  database  and  relation 
numbers.  EVTYPE  Is  a type  of  transaction  (l.e.  addition, 
deletion,  or  modification).  EVALNUMBER  is  an  alerter  number. 
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A tuple  is  interpreted  to  say  that  upon  a transaction  of  the 
specified  type  on  the  specified  relation,  the  associated 
alerting  condition  should  be  evaluated*  The  routine  that 
creates  tuples  In  the  TRANSACTIONS  relation  checks  this 
structure  after  creating  a transaction.  It  evaluates  the 
appropriate  alerting  conditions  and  triggers  the  alerter  If 
the  condition  Is  true. 

Consider  the  following  ALERT  comraands: 

ALERT  NEWPRES  (MODIFY, ADD  OF  PEOPLE)  - 
ROOM .NEW- "BLUE" 

ALERT  NFWPHONF  (MODIFY, ADD  OF  ROOMS)  - 
MODIFY  AND 

EXTFMSIOM.OLD  NEO  E XTENST ON . N EW  OR 
ADD 

ALERT  NFWPRES  = DISABLE 

These  alerter  definitions  would  be  stored  as  follows: 

AL ERTS ( p r e f 1 X column  names  by  AL) 

DB#  NAME  # ENABLE  TEXT(same  as  definition) 

I NEWPRPS  I NO 

1 NFWPUONE  2 YFS  — i 

1 

EVALUATFAI.  ERT  (prefix  column  names  by  EV) 
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PEL# 

TYPE  AL# 

1 

1 

M 1 

1 

1 

A 1 

1 

> 

M 2 

1 

2 

A 2 

DB/PROGRAM 

is  a program  written  using  the  techniques  of 

step-wise  program  c ompos 1 1 Ion t 7 ] . The  program  can  be 
divided  Into  eight  modules.  Each  module  has  knowledge  of 
only  the  data  structures  and  procedures  declared  in  a lower 
level  module.  The  hlerarchlal  ordering  of  the  eight  modules 
a re : 

ouTPitr 

INPUT 

SCAN 

DATABASE 

PECORPS 

1 oc  1 s 

eva  luatealert 
s to  re  trans 

TIME 

UTILITY 


ma  p 
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SYNTAX 

The  function  of  the  first  three  modules  (OUTPUT,  INPUT,  and 
SffAN)  are  standard  to  most  1 nt  erp  re  tors . The  DATABASE  module 
retrieves  data  from  the  database.  The  RECORDS  module 
contains  three  malor  routines.  These  routines  are  LOCIS, 
EVALUATEALERT,  and  STORETRANS.  LOCIS  Is  passed  a relation 
number.  This  routine  locates  a tuple  of  INDEXSETS 
containing  the  same  key  value  as  KEYS [ re  la t Ion  number]. 
EVALUATE AL ERT  is  a routine  passed  an  alert  number  and 
evaluates  that  alerter  based  upon  the  old  and  new  values  of 
the  tuple  being  changed.  STORETRANS  Is  the  routine  that 
updates  th*e  database.  This  routine  maintains  the 
TRANSACTIONS  and  INDEXSETS  relations  and  decides  which 
alerters  are  to  be  evaluated  based  on  the  change  to  the 
database.  The  TIME  nodule  contains  routines  to  allow  the 
database  to  be  viewed  from  previous  points  In  time.  The 
UTILITY  module  contains  the  MAP  routine.  This  routine  Is 
passed  a parameter  called  OP.  OP  specifies  whether  keys  are 
allowed,  non  keys  are  allowed,  the  records  array  should  be 
cleared,  the  keys  array  should  be  cleared,  or  if  the  old 
tuple  should  be  saved.  Its  basic  function  Is  to  process  the 
mapping  (l.e.  RELATION  (doma In-va lue ,doma ln>va lue ) ) and  fill 
the  KEYS,  RECORDS,  and  OLDPECORD  arrays  based  upon  the 
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napping  and  value  of  0P«  The  SYNTAX  module  contains  a 
I 

procedure  per  command.  Each  procedure  calls  routines  on  the 
lower  level  to  perform  that  command.  An  ADD  command  would 
proceed  as  follows. 

1.  MAP  Is  called  to  syntax  the  command  and  fill  the 

arrays.  The  value  of  OP  would  be  clear  keys,  clear 
record,  keys  allowed,  and  non  keys  allowed. 

2.  LOCIS  is  called  to  verify  that  no  tuple  exists  with 

the  same  key  value  as  Is  being  added. 

3.  STORETPANS  Is  called  to  store  the  transaction  In  the 

da  tabase 

4.  EVALIIAIKALERT  is  called  for  each  alerter  that  la  to 

be  evaluated  upon  the  addition  to  the  specified 
relation.  E VALHATEAL ERT  determines  If  the  alerter 
should  be  triggered. 

Appendix  (’  contains  syntax  diagrams  and  semantic 
definitions  for  the  database  manipulation  language. 
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CHAPTER  IV 

A likely  criticism  of  the  DATA  System  Is  the  amount  of 
storage  used.  Transactions  are  never  deleted  from  the 
database  and  consequently  it  is  constantly  growing.  One 
solution  to  this  problem  is  to  archive  transactions  before  a 
given  time  onto  a less  expensive  mode  of  storage.  Eventually 
these  transactions  could  be  discarded  and  questions  about 
them  could  not  be  answered.  This  is  analogous  to  a typical 
business  procedure.  When  a memo  is  received  it  is  usually 
placed  on  a desk  (fast  retrieval  device).  After  the  memo  la 
read  it  is  filed  away  (archived  to  a less  expensive  device). 
Eventually  memos  from  that  year  are  unimportant  and 
discarded.  Another  solution  to  the  storage  problem  is  to 
provide  a garbage  collection  algorithm  to  discard  unwanted 
transactions.  This  is  also  analogous  to  a typical  business 
procedure.  When  a filing  cabinet  becomes  full,  somebody  may 
go  through  it  to  consolidate  and  discard  memos.  The 
algorithm  used  in  determining  what  to  consolidate  and  what 
to  discard  is  the  garbage  collection  algorithm.  Another 
solution  to  the  storage  problem  is  a possible  hardware 
breakthrough.  If  mass  storage  were  to  become  extremely 
inexpensive,  there  would  be  very  little  concern  about  the 
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amount  of  storage  used. 

It  has  been  proposed  that  a tuple  consist  of  two 
distinct  portions.  One  portion  would  contain  the  relatively 
constant  domains  and  the  other  portion  would  contain  the 
dynamic  domains.  The  relatively  constant  domains  and  the 
dynamic  domains  would  be  stored  separately.  The  advantages 
of  this  approach  are  derived  from  the  fact  a smaller  portion 
of  the  tuple  needs  to  be  copied  when  a modification  occurs. 
This  leads  to  less  storage  used  and  quicker  updates.  The 
disadvantage  is  that  assertions  about  the  frequency  of 
modification  of  the  domains  are  made  at  database  definition 
time. 
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The  DATA  Svstem  has  properties  that  make  It  ideal  for 
many  applications.  The  applications  that  will  be  discussed 
deal  with  security,  history,  monitoring  changes,  online 
systems,  and  ad hoc  inquiries. 

The  fact  there  is  a complete  history  of  all  changes  to 
the  database  is  Ideal  for  security.  Viewing  the  database  as 
a series  of  transactions  would  make  It  easier  to  detect 
Improprieties.  Instead  of  having  a very  large  collection  of 
records  and  trying  to  detect  Improprieties  In  them,  dynamic 
databases  Isolate  all  changes  Into  a small  series  of 
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transactions  which  can  be  scanned  for  Improprieties.  The 
Impropriety  can  be  viewed  from  the  point  In  time  at  which  it 
occurred.  Alerters  could  be  used  to  detect  abnormal  changes 
in  the  database.  Once  an  Impropriety  has  been  Identified  It 
can  be  traced  to  a series  of  transactions  which  may  help  to 
Identify  the  culprit. 

Applications  Interested  In  past  states  of  the  entitles 
are  suited  for  the  DATA  System.  Many  applications  fall  Into 
this  category.  Using  conventional  database  techniques  the 
user  Is  forced  to  simulate  time  stamped  transaction 
databases.  For  example,  consider  a personnel  system  keeping 
a history  of  employee  salaries.  This  Information  could  be 
stored  In  a structure  as  follows: 

PEOPLR  RFT.ATION  ( 

EMPLOYEF.NUM  KEY  NUMBER; 

ADDRESS  ALPHA  20; 

NAME  ALPHA  20  ); 

SALARIES  RELATION  ( 

EMPLOYF.FNUM  KEY  NUMBER; 

DATE  KEV  alpha  A; 


1 

i 
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SALARY  NUMBER) ; 
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The  SALARIES  relation  amounts  to  a time  stamped  list  of 
transactions  of  salary  changes.  Using  the  DATA  System  a 
natural  representation  of  this  model  would  be: 

PEOPI.E  RFl  ATIOM  ( 

EMPLOY  KENIIM  KEY  NUMBER; 

ADDRESS  ALPHA  20; 

NAME  ALPHA  20; 

SALARY  NUMBER  ) 

The  DATA  System  does  the  work  for  the  user  and  provides  a 
more  natural  representation  for  Che  data.  Any  questions 
Chat  the  conventional  database  can  answer  can  be  answered  by 
the  DATA  System. 

The  DATA  System  has  been  shown  to  be  a practical  way  to 
Implement  alerting.  The  database  can  be  viewed  at  past  times 
and  thus  the  database  may  be  updated  while  evaluation  of  a 
complex  alerting  condition  occurs.  Two  applications  that  are 
Ideal  for  monitoring  changes  via  alerting  are  economic 
models  and  Inventory  control. 

Some  applications  are  required  to  be  online  for  long 
periods  of  time  and  still  require  reports  to  be  generated. 
This  has  lead  to  awkward  models  In  order  that  the  reports 
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may  be  generated  with  consistent  data.  The  DATA  System 
could  discard  these  awkward  models  because  they  provide  the 
ability  to  freeze  a program's  view  of  the  database.  Thus 
online  updating  of  the  database  could  continue  while  the 
report  was  being  generated. 

Some  applications  deal  with  adhoc  Inquiries.  These 
systems  are  asked  to  respond  to  questions  they  have  no 
aprlorl  knowledge  of.  A DATA  database  never  discards  any 
Information  and  thus  would  be  best  able  to  answer  the 
Inquiry.  The  Information  Is  well  stuctured,  and  this 
structure  Is  knot^rn  to  the  system.  A management  Information 
system  Is  an  example  of  such  a system. 

DATA  has  provided  Ideas  for  future  research.  One 
project  would  he  to  embed  the  facilities  of  DATA  into  a 
programming  language.  For  DATA  to  reach  Its  full  potential 
the  database  system/user  program  Interface  should  be  a 
message  passing  system.  This  means  that  both  the  user 
program  and  database  system  would  send  and  receive  messages. 
After  a message  Is  sent,  the  user  program  (or  database 
system)  continues  on  other  work  and  later  handles  the 


response  (and  any  other  requests)  to  the  message.  Another 

« 

project  could  he  to  Investigate  techniques  to  decrease  the 
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amount  of  storage  used  by  HATA.  Currently  DATA  supports  only 
three  types  of  transactions*  These  are  ADD,  DELETE,  and 
MODIFY.  It  might  be  possible  for  the  user  to  define  higher 
level  transactions  such  as  "salary  Increase".  The  user 
would  also  provide  the  routines  to  apply  the  semantics  of 
such  a transaction.  Another  area  of  research  would  be  to 
use  DATA  to  Implement  more  complex  forms  of  alerting.  This 
system  would  use  DATA' s simple  alerters,  ability  to  view  the 
database  as  a series  of  transactions,  and  ability  to  view 
the  database  at  previous  points  In  time  to  Implement  the 
complex  alerting. 

The  DATA  System  provides  an  alternative  to  the 
conventional  database  management  system.  It  has  advantages 
In  the  areas  of  security,  integrity,  and  operational  ease. 
The  DATA  System  Is  an  excellent  framework  on  which  to  build 
an  alerting  system.  An  alerting  system  provides  the  ability 
to  have  the  system  monitor  changes  In  the  database  and 
notify  the  user  when  conditions  of  Interest  become  true.  A 
conclusion  of  this  thesis  Is  that  the  only  type  of  alerting 
the  system  should  provide  Is  simple  alerting.  Users  can 
supply  programs  that  use  simple  alerting  to  note  changes  In 
the  database.  These  programs  evaluate  the  more  complicated 
alerting  conditions.  This  concept  depends  upon  the  feature 
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APPENniX  A:  RAILROAD  DIAGRAMS [8] 

Railroad  diagrams  show  how  synCatically  valid 
statements  can  he  constructed.  Traversing  a railroad 
diagram  from  left  to  right,  or  In  the  direction  of  arrow 
heads  will  produce  a syntatlcally  valid  statement. 
Continuation  from  one  line  of  a diagram  to  another  Is 
represented  hy  a capital  0 "0"  at  then  end  of  the  current 
and  the  beginning  of  the  next  line.  The  complete  syntax 
diagram  Is  terminated  by  double  slashes  "//”•  A star  Is 

used  to  hlghllte  intersection  points.  The  various  arrow 
heads  are  left  arrow  head  right  arrow  head  upward 

arrow  head  "A"  and  downward  arrow  head  "V".  Items  contained 
In  broken  hrakets  "<  >"  are  syntatlcal  variables  which  are 
further  defined.  For  example: 


> REOniRFD  ITEM * > * >// 

V A 
* — > .OPTION  2 — * 

V A 
* — > .OPTION  3 — * 


produces  the  following  syntatlcal  valid  statements: 
REOUIRED  ITEM 
REOUTREn  ITEM, OPTION  2 


RFOITIRED  ITEM, OPTION  3 
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APPENDIX  B:  DATABASE  DEFINITION 


SYNTAX: 

<database  definitlon> 

--->  <database  name>  — ->  DATABASE  o 

* ; < * 

V A 
0--->  ( -*->  <relatlon  definltlon> 

V A 

<relation  deflnttion> 

> <relatton  name>  --->  RELATION  0 

* . < * 

V A 

0--->  ( -* > <domaln  deflnition> 

V A 

<domaln  definitlon> 

->  <domaln  na(re>  ALPHA  ->  <slze>  -*->// 

V A V A 

*->  KEY  -*  * > NUMBER * 

<database  naffle> 

--->  <ldentlfler>  --->// 

<relatlon  nante> 

--->  <ldentlfler>  --->// 


<domaln  name> 
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APPENDIX  C;  DATABASE  MANIPULATION 


<baslc  coinmands> 


-* > odd  coroinand>  

V 

*  > olert  coniffland>  -• 

V 

*  > <bye  command>  ---• 

V 

*  > <deleCe  conimand>  ■ 

V 

*  > <dlsplay  coninand> 

V 

*- > <flnd  cominand> 


*  > <modify  command>  -■ 

V 

*---->  <rollback  comnand> 

V 

*- > Oettlme  coniniand>  • 

V 

*  > <show  coin(nand>  — -• 


The  DATABASE  f*  AN  I P ULATI  ON  LANCUAGE  consists  of  ten  commands 
used  to  access  the  database.  These  commands  are  the  add, 
alert,  bye,  delete,  display,  find,  modify,  rollback, 
settime,  and  show  commands. 


I 

i 
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SYNTAX: 


> ADD 


<add  command> 


•>  <relatlon  name> 


V A 

0 -*->  <domaln  name>  -->  <eql  op>  *->  <s t ring> -*-*-->)->/ / 

V A 

*->  <number>  * 


SEMANTICS : 

1.  The  <add  command>  causes  a tuple  of  <relatlon  name>  to  be 
created  and  stored  Into  the  database.  An  exception  Is 
returned  if  a tuple  already  exists  with  a key  value 
Identical  to  the  specified  values. 

2.  The  value  for  any  alpha  domain  not  mentioned  Is  blank. 

The  value  for  any  number  not  mentioned  Is  zero.  Both  keys 
and  nonkeys  can  be  used  for  <domaln  name>  In  a <add 
command> . 

3.  Domains  of  type  ALPHA  must  have  <strlng>s  assigned  to 
them  and  domains  of  type  NUMBER  must  have  <number>s 
assigned  to  them. 

4.  The  tuple  stored  becomes  the  current  tuple  of  <relatlon 

name  > . 


<alert  command> 


SYNTAX; 

<alert  commands 

> ALFRT  -* > * > *->// 

''  A A 

*->  <alert  name>  <alert  8pec>  -* 


<alerc  name> 

--->  <identlfler>  --->// 


<alert  spec> 

(<evaliiate  condi  tlon>)  <e<jl  op>  <condition>  >*->// 


V A 

*-->  <eql  op> > <alert  scace>  * 


<evaluate  condltIon> 

< — * 

A 

riRLFTE  * — > OF->  <relaCion  name>  -->// 

A 

ADP * 

A 

MODIFY  — * 


<alert  staCe> 

> CANCEL * >// 

A 

> ENAFLF  * 

A 

> PISABLE  * 


* 

V 

* 

V 

* 
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<relatlon  op> 

* > 

V 

V 

* > 

V 

* > 

V 

* > 

V 

*_ > 


<neq  op> 
< 1 eq  op  > 

< R t r op  > 
< 1 s s op  > 

< e q 1 op  > 

< g e q op  > 


<neq  op> 


*_,__>  MFO *-->// 

V A 

A — _ — — > ''s  - — — _ — — * 


<leq  op> 


*  > LEO * — >// 

V A 

*  > <» * 


<Rtr  op> 


*  > nxp *-->// 

V A 

*  > > * 


<ls 3 op> 


*  > l,SS * — >// 

V A 

*  > < * 


<eql  op> 


*  > f.QL * — >// 

V A 

*  > * 


>// 


> <arlth  prlmary>  — -- 


<arlth  op> 

V 

* > - 

V 

* > + 

V 

* > / 


- * >// 

A 



A 




A 

* 


<arlth  prlmary> 


* > <arlth  doinaLn>  * ->// 

V A 

* — > ( ->  <arlth  exp>  ->  ) * 

V A 

> <nuinber>  * 


<numbe  r > 


*____>  — — _ — * 

V A 

*__>  + * 

V A 
*— _>  — — 


> <lnteger> 


* 

V 

*-->  •<ititeger> 


<arlth  domaln> 


->// 


> <doinaln  name> 


< time  > 


<t  inie> 

* > OLD *-->// 

V A 

' > NEW * 


<string  exp> 

— > <strlng> 

V A 

*---->  <alpha  domaln>  ---* 


<alpha  domaln> 

--->  <domaln  naine>  . <time>  --->// 


<boolean  functlon> 

* > pelftb * >// 

V A 

*  > modify * 

V A 

*  > ADD * 
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SEMANTICS  : 

1.  ALERT  hy  itself  will  list  the  nanes  of  all  known 
alerters • 

2«  ALERT  <alert  naine>  will  list  the  text  associated  with 
<alert  name>  and  the  current  state  of  the  alerter. 

3.  ALERT  <alert  name>  ■ CANCEL  will  cancel  <alert  name>. 

A.  ALERT  <alert  name>  (<evaliiate  condition>)  ■ <condltlon> 
creates  an  alerter*  <evaluate  conditlon>  specifies  under 
what  circumstances  to  evaluate  <condltlon>.  When 
<condltlon>  evaluates  true  then  the  <alert  name>  and 
transaction  number  will  be  displayed  at  the  terminal* 

5*  When  an  alerter  Is  being  evaluated  two  tuples  can  be 
viewed*  These  are  the  tuples  before  and  after  the 
modification*  If  the  transaction  being  evaluated  is  a 
deletion  or  addition,  the  two  tuples  are  identical* 

6*  ALERT  <alert  name>  ■ ENABLE  enables  an  alerter*  An 

alerter  being  enabled  means  it  may  be  triggered*  After 
an  alerter  is  created  it  is  enabled* 

7*  ALERT  <alert  name>  DISABLE  disables  an  alerter*  An 
alerter  being  disabled  means  it  may  not  be  triggered. 


<bye  cominand> 


SYNTAX: 

> bye >// 

SEMANTICS  : 

1.  The  <hye  c oTPina nd > causes  the  end  of  the  session* 
changes  to  the  database  are  saved  between  sessions 
Alerter  definitions  and  states  are  saved  between 


All 


sess Ions 
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<delete  command> 


SYNTAX: 

___>  peI.ETE -->  <relation  name> 


0 -*->  <doinaln  naDie>  -->  <eql  op>  *->  <8trlng>  -*-*->)->// 

V A 

*->  <nun)ber>  -* 


SEMANTICS  : 

1.  The  <delete  command>  causes  a tuple  of  <relatlon  name>  to 
be  located  and  deleted  from  the  database*  An  exception  Is 
returned  if  a ^uple  does  not  exist  with  a key  value 
identical  with  the  key  value  specified* 

2*  The  default  value  for  any  alpha  keys  not  mentioned  Is 
blank*  The  default  value  for  any  numeric  key  not 
mentioned  Is  zero*  Only  keys  can  be  used  for  <domaln 
name>  In  the  <delete  command>* 

3*  Keys  of  type  ALPHA  must  be  compared  against  <strlng>8  and 
keys  of  type  NUMBER  must  be  compared  against  <number>s* 

* There  Is  no  current  tuple  of  <relatlon  name>  after  this 
command  is  complete* 
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i 

<dlsplay  coininand> 

SYNTAX: 

> DISPLAY > <relatlon  name> >// 

SEMANTICS  : 

1.  The  <display  cotnmand>  causes  the  current  tuple  of 
<relatlon  nanie>  to  be  output*  Each  line  output  contains 
cdonaln  name>  and  the  value  of  <doiDaln  name>  In  the 

current  tuple  . | 

1 

2.  An  exception  Is  returned  If  there  is  no  current  tuple  of 
<rela t Ion  name >. 
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<flnd  command> 

SYNTAX; 

--->  FIND  > <relatlon  narae>  ( -->  o 


C -*->  <domaln  name>  -->  <eql  op>  *->  <3trlng>  -*-*->)->// 

V A 

*->  <number>  -* 


SEMANTICS  ; 

1.  The  <flnd  cominand>  causes  a tuple  of  <relatlon  name>  to 
be  located.  An  exception  Is  returned  if  no  tuple  exists 
with  a key  value  Identical  to  the  specified  values. 

2.  The  default  value  for  any  alpha  keys  not  mentioned  Is 
blank.  The  default  value  for  any  numeric  key  not 
mentioned  l.s  zero.  Only  keys  can  be  used  for  <domaln 
name  > . 

3.  Keys  of  type  ALPHA  must  be  compared  against  <strlng>s  and 
keys  of  type  NUMBER  must  be  compared  against  <number>s. 

4.  The  tuple  located  becomes  the  current  tuple  of  <relatlon 
naae>  after  this  command  Is  complete. 


1 


I 
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<niodlfy  command> 


SYNTAX: 


--->  MOPIFY  --->  <relatlon  name>  ( -->0 


O <domain  name>  -->  <eql  op>  *->  <string>  -*-*->)->// 

V A 

*->  <number>  -* 


SEMANTICS : 

!•  The  <modlfy  coinmand>  causes  the  current  tuple  of 

<relation  naine>  to  be  modified  and  to  be  stored  into  the 
database.  An  exception  Is  returned  If  there  is  no  current 
tuple  of  <relatlon  name>. 

2.  The  keys  of  a tuple  nay  not  be  changed.  Therefore,  only 
nonkeys  may  be  used  In  a <modlfy  command>. 

3.  Pomalns  of  type  ALPHA  must  have  <strlng>s  assigned  to 
them  and  domains  of  type  NPMRER  must  have  <number>s 
assigned  to  them. 

4.  The  tuple  modified  remains  the  current  tuple  of  <relatlon 


name> 


<rollback  cominand> 


--->  <lnteger>  ---->// 


f j 

i , I 

I <year>  'i 

l ; 

--->  / > <lnteger>  >// 

<hour > 

I 

> g > <lnteger> >// 

<mlnute> 

--->  ; --->  <lnteger>  --->// 

t 

<8econd> 

> ; --->  <lnceger>  >// 

SEMANTICS : 

1.  ROLLBACK  causes  the  database  to  be  backed  up  to  the  point 


In  tine  specified. 
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<setttnie  cominand> 


SYNTAX: 

<settlt!'.e  command> 

> SETTIME * > *->// 

V A 

*->  <eql  op>  -->  <settlnie  tlme> 

<8ettlffle  tline> 

* > CURRENT * >// 

V A 

*--->  <past  clne> 

SEMANTICS: 

1.  SETTIMF  by  Itself  causes  the  time  from  which  the  database 
Is  being  viewed  to  be  displayed. 

2.  SETTIME  - CUPPFNT  states  the  database  Is  being  viewed 
from  the  current  time.  This  Is  the  normal  mode. 

3.  SETTIME  “ <dav>  <year>  <hour>  <mlnute>  <8econd>  causes 
the  database  to  he  viewed  as  It  existed  at  that  point  In 
time.  The  add,  delete,  and  modify  commands  may  not  be 
executed  until  a SETTIME  « CURRENT  la  executed. 
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<show  coinmand> 

SYNTAX; 


> SHOW * > * >// 

V A 

*-->  <relaclon  name>  --- — 


SEMANTICS : 

1.  SHOV7  by  Itself  causes  the  list  of  <relatlon  name>s  to  be 
output  • 

2.  SH0V7  <relatlon  name>  causes  the  list  of  <doinaln  naine>s 
within  <relatlon  name>  to  be  output.  Along  with  the 
<donialn  name>  Its  type,  key  status,  and  size  are  output. 
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